1. Field of the Invention
The present invention generally relates to the art of industrial control systems, and more specifically to a distributed digital control system including modules with multiple stored databases and a selector.
2. Description of the Related Art
A simple digital control system includes a single processor or controller to which various input and output devices such as sensors and actuators are connected. The controller is programmed to make decisions and control the actuators based on information obtained from the sensors. This type of system is typically implemented with a microprocessor based controller, with its sensors and actuators in relatively close proximity to facilitate their direct connection to the controller electronics.
In cases where the sensors and/or actuators are not located near the controller, a transmission medium or communication link is employed to transmit information between the controller and the remote devices. Conventional transmission media include 4 to 20 milliamp current loops, simple digital serial interfaces such as RS-232, and Local Area Networks (LAN), with the controller being located at a central point.
A distributed control system uses multiple controllers instead of a single central controller. The system functions are segmented into discrete tasks and divided between the various controllers. The information necessary to coordinate the overall system is then communicated between the controllers by a medium which is suitable for the particular application, such as a shared memory space, or more typically a LAN.
There are two ways to organize distributed control systems; client/server and peer to peer. In a typical client/server system, one of the controllers functions as a server and the remaining controllers function as clients. The server acts a system coordinator. All shared information is located at the server and may not be passed directly between clients. Conventional office computer networks and the Internet are examples of client/server systems.
In a peer to peer system, communication takes place directly between the processors without having to go through an immediate server. Controllers exchange information using special program variables known as system variables. Changes in the value of a system output variable on one controller are communicated to another controller's system input variable, and thus the same value is maintained for both variables. Not all system output variables are communicated to all system input variables, but those variables that are communicated are said to be "connected" or "bound". The establishment of these connections is referred to as binding. Peer to peer systems are typically used in distributed control applications such as factory automation or building energy control systems.
Controllers in a peer to peer system often have their program functions divided into discrete units known as objects. Each object can have one or more system input or output variables. Objects are designed to be general purpose building blocks which may be used in various combinations to achieve a desired system function. Although each individual object has a fixed function, the overall operation or relationship of the objects to one another, as defined by the system variable connections, is not fixed, but may be changed to accomplish the desired system level result. Objects may also have operating parameters which may be specified in each instance to adjust for varying operating conditions.
A systems designer typically uses a computer program, referred to as a management tool, to define the system variable connections and the operating parameter values for each of the objects on the controllers. When a new controller is installed, it must be configured by the management tool before it can assume any role within the system. This is true both when the individual controllers are first brought together as a system, and whenever a controller is replaced for maintenance reasons. Therefore, the presence of a management tool, and its operator, is required both at the initial assembly point and the field service point.
For many distributed control systems, the two management points (assembly and service) are one and the same. This is true when a system is not physically moved to another location after it is installed. A good example of this is a factory automation system, where it is practical for the same management tool and operating personnel to be used for both system installation and maintenance.
For an Original Equipment Manufacturer (OEM) product which incorporates an embedded distributed control system, the two management points are not the same, and both present problems which many times make such systems impractical. At the assembly point, systems are installed not only once, as in the factory automation case, but over and over again, each time the product is assembled, thus complicating the manufacturing process. The larger problem, however, is at each remote point to which the product is shipped, where a management tool and qualified operator are required for field service.
Each controller in a distributed system requires three types of memory: a program memory which is a non-volatile storage space containing the program instructions which direct the operation of the controller, and is often implemented using read-only memory, and a scratch-pad memory which is a random access memory used for intermediate values (results of calculations, program stack, etc.) that do not have to be permanently stored. These first two memory types are universal to all microprocessor based controllers.
The third type of memory, unique to distributed controllers, is a system database. The system database is a record of the system variable connections and the operating parameter values for each object on the controller. This memory must be non-volatile to preserve the information which determines the overall operation of a system, and is usually a read/write type memory to enable database updates. The role of a management tool is to generate the information to be contained in the system database, and to transfer the information into the controller's system database.
One way to completely eliminate the need for a management tool in an OEM system is to put the system database into non-volatile read-only memory. This is sometimes referred to as a pre-configured system. One drawback to this is that many or all of the controllers within the system are often exactly the same physically, with the only distinction between them being the contents of the system database.
Placing a different system database into each controller's read-only memory forces the stocking and labeling, at both manufacturing and field service points, of a separate unit for each of the controllers, which can be not only cumbersome, but confusing since the controllers all look for the same. This is contrasted to stocking only a single item, which is used in multiple instances, for systems using a management tool to update the system database each time a controller is installed.
A second drawback to pre-configured systems is inflexibility. An OEM may ship systems to multiple customers, with each one requiring a different system database configuration. This again comes down to an inventory control issue, since the stocking problems described above are now multiplied by the number of customers.